रिएक्ट का रहस्य: रिकंसिलिएशन एल्गोरिथम और वर्चुअल DOM डिफिंग का गहन विश्लेषण

` को इस तरह दर्शाया जा सकता है:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

चूंकि ये सिर्फ जावास्क्रिप्ट ऑब्जेक्ट हैं, इसलिए इन्हें बनाना और इनमें हेरफेर करना अविश्वसनीय रूप से तेज़ है। इसमें ब्राउज़र APIs के साथ कोई इंटरैक्शन शामिल नहीं है, इसलिए कोई रिफ्लो या रिपेंट नहीं होता है।

वर्चुअल DOM कैसे काम करता है?

VDOM यूआई विकास के लिए एक घोषणात्मक दृष्टिकोण को सक्षम बनाता है। ब्राउज़र को यह बताने के बजाय कि DOM को चरण-दर-चरण कैसे बदलना है (अनिवार्य), आप बस यह घोषित करते हैं कि किसी दिए गए स्टेट के लिए यूआई कैसा दिखना चाहिए (घोषणात्मक)। बाकी काम रिएक्ट संभालता है।

यह प्रक्रिया इस तरह दिखती है:

1. प्रारंभिक रेंडर: जब आपका एप्लिकेशन पहली बार लोड होता है, तो रिएक्ट आपके यूआई के लिए एक पूर्ण वर्चुअल DOM ट्री बनाता है और इसका उपयोग प्रारंभिक वास्तविक DOM उत्पन्न करने के लिए करता है।
2. स्टेट अपडेट: जब एप्लिकेशन की स्टेट बदलती है (उदाहरण के लिए, एक उपयोगकर्ता एक बटन पर क्लिक करता है), तो रिएक्ट एक नया वर्चुअल DOM ट्री बनाता है जो नई स्टेट को दर्शाता है।
3. डिफिंग: अब रिएक्ट के पास मेमोरी में दो वर्चुअल DOM ट्री हैं: पुराना (स्टेट परिवर्तन से पहले) और नया। फिर यह इन दोनों ट्री की तुलना करने और सटीक अंतरों की पहचान करने के लिए अपना "डिफिंग" एल्गोरिथम चलाता है।
4. बैचिंग और अपडेटिंग: रिएक्ट वास्तविक DOM को नए वर्चुअल DOM से मेल खाने के लिए आवश्यक संचालन का सबसे कुशल और न्यूनतम सेट गणना करता है। इन ऑपरेशनों को एक साथ बैच किया जाता है और एक ही, अनुकूलित अनुक्रम में वास्तविक DOM पर लागू किया जाता है।

अपडेट को बैच करके, रिएक्ट धीमे DOM के साथ सीधे इंटरैक्शन को कम करता है, जिससे प्रदर्शन में काफी सुधार होता है। इस दक्षता का मूल "डिफिंग" चरण में निहित है, जिसे औपचारिक रूप से रिकंसिलिएशन एल्गोरिथम के रूप में जाना जाता है।

रिएक्ट का हृदय: रिकंसिलिएशन एल्गोरिथम

रिकंसिलिएशन वह प्रक्रिया है जिसके माध्यम से रिएक्ट नवीनतम कंपोनेंट ट्री से मेल खाने के लिए DOM को अपडेट करता है। इस तुलना को करने वाले एल्गोरिथम को हम "डिफिंग एल्गोरिथम" कहते हैं।

सैद्धांतिक रूप से, एक ट्री को दूसरे में बदलने के लिए न्यूनतम संख्या में परिवर्तनों को खोजना एक बहुत ही जटिल समस्या है, जिसकी एल्गोरिथम जटिलता O(n³) के क्रम में है, जहाँ n ट्री में नोड्स की संख्या है। यह वास्तविक दुनिया के अनुप्रयोगों के लिए बहुत धीमा होगा। इसे हल करने के लिए, रिएक्ट की टीम ने कुछ शानदार अवलोकन किए कि वेब एप्लिकेशन आमतौर पर कैसे व्यवहार करते हैं और एक अनुमानी एल्गोरिथम लागू किया जो बहुत तेज़ है—O(n) समय में काम करता है।

अनुमानी नियम (Heuristics): डिफिंग को तेज़ और पूर्वानुमानित बनाना

रिएक्ट का डिफिंग एल्गोरिथम दो प्राथमिक मान्यताओं या अनुमानी नियमों पर बनाया गया है:

अनुमानी नियम 1: विभिन्न एलिमेंट प्रकार विभिन्न ट्री उत्पन्न करते हैं

यह पहला और सबसे सीधा नियम है। दो VDOM नोड्स की तुलना करते समय, रिएक्ट पहले उनके प्रकार को देखता है। यदि रूट एलिमेंट्स का प्रकार अलग है, तो रिएक्ट यह मान लेता है कि डेवलपर एक को दूसरे में बदलने की कोशिश नहीं करना चाहता है। इसके बजाय, यह एक अधिक कठोर लेकिन पूर्वानुमानित दृष्टिकोण अपनाता है:

• यह पूरे पुराने ट्री को ध्वस्त कर देता है, सभी पुराने कंपोनेंट्स को अनमाउंट करता है और उनकी स्टेट को नष्ट कर देता है।
• यह नए एलिमेंट प्रकार के आधार पर स्क्रैच से एक पूरी तरह से नया ट्री बनाता है।

उदाहरण के लिए, इस बदलाव पर विचार करें:

पहले: <div><Counter /></div>
बाद में: <span><Counter /></span>

भले ही चाइल्ड `Counter` कंपोनेंट वही है, रिएक्ट देखता है कि रूट `div` से `span` में बदल गया है। यह पुराने `div` और उसके भीतर के `Counter` इंस्टेंस को पूरी तरह से अनमाउंट कर देगा (उसकी स्टेट खो देगा) और फिर एक नया `span` और `Counter` का एक बिल्कुल नया इंस्टेंस माउंट करेगा।

मुख्य बात: यदि आप किसी कंपोनेंट सबट्री की स्टेट को संरक्षित करना चाहते हैं या उस सबट्री के पूर्ण री-रेंडर से बचना चाहते हैं, तो उसके रूट एलिमेंट प्रकार को बदलने से बचें।

अनुमानी नियम 2: डेवलपर्स `key` प्रॉप के साथ स्थिर एलिमेंट्स का संकेत दे सकते हैं

यह यकीनन डेवलपर्स के लिए समझने और सही ढंग से लागू करने के लिए सबसे महत्वपूर्ण अनुमानी नियम है। जब रिएक्ट चाइल्ड एलिमेंट्स की सूची की तुलना करता है, तो उसका डिफ़ॉल्ट व्यवहार दोनों सूचियों के बच्चों पर एक ही समय में पुनरावृति करना और जहाँ भी कोई अंतर होता है, वहाँ एक म्यूटेशन उत्पन्न करना होता है।

इंडेक्स-आधारित डिफिंग के साथ समस्या

आइए कल्पना करें कि हमारे पास आइटम्स की एक सूची है और हम कीज़ (keys) का उपयोग किए बिना सूची की शुरुआत में एक नया आइटम जोड़ते हैं।

प्रारंभिक सूची:

• आइटम B
• आइटम C

अपडेट की गई सूची (शुरुआत में 'आइटम A' जोड़ें):

• आइटम A
• आइटम B
• आइटम C

कीज़ के बिना, रिएक्ट एक सरल, इंडेक्स-आधारित तुलना करता है:

1. यह पुराने आइटम को इंडेक्स 0 ('आइटम B') पर नए आइटम से इंडेक्स 0 ('आइटम A') पर तुलना करता है। वे अलग हैं, इसलिए यह पहले आइटम को म्यूटेट करता है।
2. यह पुराने आइटम को इंडेक्स 1 ('आइटम C') पर नए आइटम से इंडेक्स 1 ('आइटम B') पर तुलना करता है। वे अलग हैं, इसलिए यह दूसरे आइटम को म्यूटेट करता है।
3. यह देखता है कि इंडेक्स 2 ('आइटम C') पर एक नया आइटम है और उसे सम्मिलित करता है।

यह अत्यधिक अकुशल है। रिएक्ट ने दो अनावश्यक म्यूटेशन और एक इंसर्शन किया है, जबकि जरूरत केवल शुरुआत में एक सिंगल इंसर्शन की थी। यदि ये सूची आइटम अपनी स्टेट के साथ जटिल कंपोनेंट होते, तो यह गंभीर प्रदर्शन समस्याओं और बग्स का कारण बन सकता था, क्योंकि स्टेट कंपोनेंट्स के बीच मिल सकती थी।

`key` प्रॉप की शक्ति

`key` प्रॉप एक समाधान प्रदान करता है। यह एक विशेष स्ट्रिंग एट्रिब्यूट है जिसे आपको एलिमेंट्स की सूची बनाते समय शामिल करने की आवश्यकता होती है। कीज़ रिएक्ट को प्रत्येक एलिमेंट के लिए एक स्थिर पहचान देती हैं।

आइए उसी उदाहरण पर फिर से विचार करें, लेकिन इस बार स्थिर, अद्वितीय कीज़ के साथ:

प्रारंभिक सूची:

• आइटम B
• आइटम C

अपडेट की गई सूची:

• आइटम A
• आइटम B
• आइटम C

अब, रिएक्ट की डिफिंग प्रक्रिया बहुत स्मार्ट है:

1. रिएक्ट नई सूची के बच्चों को देखता है और 'b' और 'c' कीज़ वाले एलिमेंट्स को ढूंढता है।
2. यह जानता है कि 'b' और 'c' कीज़ वाले एलिमेंट्स पुरानी सूची में पहले से मौजूद हैं, इसलिए यह बस उन्हें स्थानांतरित करता है।
3. यह देखता है कि 'a' की के साथ एक नया एलिमेंट है जो पहले मौजूद नहीं था, इसलिए यह उसे बनाता और सम्मिलित करता है।

यह कहीं अधिक कुशल है। रिएक्ट सही ढंग से पहचानता है कि उसे केवल एक इंसर्शन करने की आवश्यकता है। 'b' और 'c' कीज़ से जुड़े कंपोनेंट संरक्षित रहते हैं, और अपनी आंतरिक स्टेट बनाए रखते हैं।

कीज़ के लिए महत्वपूर्ण नियम: कीज़ अपने सिबलिंग्स के बीच स्थिर, पूर्वानुमानित और अद्वितीय होनी चाहिए। ऐरे इंडेक्स को की के रूप में उपयोग करना (`items.map((item, index) =>

...

)`) एक एंटी-पैटर्न है यदि सूची को कभी भी फिर से क्रमबद्ध, फ़िल्टर किया जा सकता है, या बीच से आइटम जोड़े/हटाए जा सकते हैं, क्योंकि यह बिना की के होने जैसी ही समस्याओं की ओर ले जाता है। सबसे अच्छी कीज़ आपके डेटा से अद्वितीय पहचानकर्ता होती हैं, जैसे डेटाबेस आईडी।

विकास: स्टैक से फाइबर आर्किटेक्चर तक

ऊपर वर्णित रिकंसिलिएशन एल्गोरिथम कई वर्षों तक रिएक्ट की नींव थी। हालाँकि, इसकी एक बड़ी सीमा थी: यह सिंक्रोनस और ब्लॉकिंग था। इस मूल कार्यान्वयन को अब स्टैक रिकंसाइलर के रूप में जाना जाता है।

पुराना तरीका: स्टैक रिकंसाइलर

स्टैक रिकंसाइलर में, जब एक स्टेट अपडेट एक री-रेंडर को ट्रिगर करता था, तो रिएक्ट पूरे कंपोनेंट ट्री को पुनरावर्ती रूप से पार करता था, परिवर्तनों की गणना करता था, और उन्हें DOM पर लागू करता था—सब कुछ एक ही, निर्बाध अनुक्रम में। छोटे अपडेट के लिए, यह ठीक था। लेकिन बड़े कंपोनेंट ट्री के लिए, इस प्रक्रिया में काफी समय लग सकता था (जैसे, 16ms से अधिक), जिससे ब्राउज़र का मुख्य थ्रेड ब्लॉक हो जाता था। इससे यूआई अनुत्तरदायी हो जाता था, जिससे फ्रेम ड्रॉप होते थे, एनिमेशन में जर्क आता था और उपयोगकर्ता का अनुभव खराब होता था।

रिएक्ट फाइबर का परिचय (रिएक्ट 16+)

इस समस्या को हल करने के लिए, रिएक्ट टीम ने कोर रिकंसिलिएशन एल्गोरिथम को पूरी तरह से फिर से लिखने के लिए एक बहु-वर्षीय परियोजना शुरू की। इसका परिणाम, रिएक्ट 16 में जारी किया गया, जिसे रिएक्ट फाइबर कहा जाता है।

फाइबर आर्किटेक्चर को समवर्तीता (concurrency) को सक्षम करने के लिए शुरू से ही डिजाइन किया गया था—रिएक्ट की एक साथ कई कार्यों पर काम करने और प्राथमिकता के आधार पर उनके बीच स्विच करने की क्षमता।

एक "फाइबर" एक सादा जावास्क्रिप्ट ऑब्जेक्ट है जो काम की एक इकाई का प्रतिनिधित्व करता है। इसमें एक कंपोनेंट, उसके इनपुट (प्रॉप्स), और उसके आउटपुट (चिल्ड्रन) के बारे में जानकारी होती है। एक पुनरावर्ती ट्रैवर्सल के बजाय जिसे बाधित नहीं किया जा सकता था, रिएक्ट अब फाइबर नोड्स की एक लिंक्ड सूची को एक-एक करके संसाधित करता है।

इस नए आर्किटेक्चर ने कई प्रमुख क्षमताओं को अनलॉक किया:

• इंक्रीमेंटल रेंडरिंग: यह रेंडरिंग कार्य को छोटे टुकड़ों में विभाजित कर सकता है और इसे कई फ्रेमों में फैला सकता है।
• प्राथमिकता: यह विभिन्न प्रकार के अपडेट को विभिन्न प्राथमिकता स्तर प्रदान कर सकता है। उदाहरण के लिए, एक इनपुट फील्ड में टाइप करने वाले उपयोगकर्ता की प्राथमिकता पृष्ठभूमि में डेटा लाने की तुलना में अधिक होती है।
• रोकने और रद्द करने की क्षमता: यह एक उच्च-प्राथमिकता वाले अपडेट को संभालने के लिए एक निम्न-प्राथमिकता वाले अपडेट पर काम रोक सकता है, और उस काम को रद्द या पुन: उपयोग भी कर सकता है जिसकी अब आवश्यकता नहीं है।

फाइबर के दो चरण

फाइबर के तहत, रेंडरिंग प्रक्रिया को दो अलग-अलग चरणों में विभाजित किया गया है:

1. रेंडर/रिकंसिलिएशन चरण (एसिंक्रोनस): इस चरण में, रिएक्ट "वर्क-इन-प्रोग्रेस" ट्री बनाने के लिए फाइबर नोड्स को संसाधित करता है। यह कंपोनेंट `render` विधियों को कॉल करता है और यह निर्धारित करने के लिए डिफिंग एल्गोरिथम चलाता है कि DOM में क्या बदलाव किए जाने की आवश्यकता है। महत्वपूर्ण रूप से, यह चरण बाधित किया जा सकता है। रिएक्ट इस काम को कुछ और महत्वपूर्ण संभालने के लिए रोक सकता है, और बाद में इसे फिर से शुरू कर सकता है। क्योंकि इसे बाधित किया जा सकता है, रिएक्ट इस चरण के दौरान कोई वास्तविक DOM परिवर्तन लागू नहीं करता है ताकि एक असंगत यूआई स्थिति से बचा जा सके।
2. कमिट चरण (सिंक्रोनस): एक बार जब वर्क-इन-प्रोग्रेस ट्री पूरा हो जाता है, तो रिएक्ट कमिट चरण में प्रवेश करता है। यह गणना किए गए परिवर्तनों को लेता है और उन्हें वास्तविक DOM पर लागू करता है। यह चरण सिंक्रोनस है और इसे बाधित नहीं किया जा सकता। यह सुनिश्चित करता है कि उपयोगकर्ता हमेशा एक सुसंगत यूआई देखे। `componentDidMount` और `componentDidUpdate` जैसे लाइफसाइकिल मेथड्स, साथ ही `useLayoutEffect` और `useEffect` हुक्स, इस चरण के दौरान निष्पादित होते हैं।

फाइबर आर्किटेक्चर रिएक्ट की कई आधुनिक विशेषताओं की नींव है, जिसमें `Suspense`, समवर्ती रेंडरिंग, `useTransition`, और `useDeferredValue` शामिल हैं, जो सभी डेवलपर्स को अधिक उत्तरदायी और तरल यूजर इंटरफेस बनाने में मदद करते हैं।

डेवलपर्स के लिए व्यावहारिक ऑप्टिमाइज़ेशन रणनीतियाँ

रिएक्ट की रिकंसिलिएशन प्रक्रिया को समझना आपको अधिक प्रदर्शनकारी कोड लिखने की शक्ति देता है। यहाँ कुछ व्यावहारिक रणनीतियाँ हैं:

1. सूचियों के लिए हमेशा स्थिर और अद्वितीय कीज़ का उपयोग करें

इस पर पर्याप्त जोर नहीं दिया जा सकता है। यह सूचियों के लिए सबसे महत्वपूर्ण एकल ऑप्टिमाइज़ेशन है। अपने डेटा से एक अद्वितीय आईडी का उपयोग करें (जैसे, `product.id`)। ऐरे इंडेक्स का उपयोग करने से बचें जब तक कि सूची पूरी तरह से स्थिर न हो और कभी नहीं बदलेगी।

2. अनावश्यक री-रेंडर्स से बचें

एक कंपोनेंट री-रेंडर होता है यदि उसकी स्टेट बदलती है या उसका पैरेंट री-रेंडर होता है। कभी-कभी, एक कंपोनेंट तब भी री-रेंडर होता है जब उसका आउटपुट समान होता। आप इसे रोक सकते हैं:

• `React.memo()`: फंक्शन कंपोनेंट्स के लिए एक हायर-ऑर्डर कंपोनेंट। यह कंपोनेंट के प्रॉप्स की एक शैलो तुलना करता है। यदि प्रॉप्स नहीं बदले हैं, तो रिएक्ट कंपोनेंट को री-रेंडर करना छोड़ देगा और अंतिम रेंडर किए गए परिणाम का पुन: उपयोग करेगा।
• `useCallback()`: एक कंपोनेंट के अंदर परिभाषित फ़ंक्शन हर रेंडर पर फिर से बनाए जाते हैं। यदि आप इन फ़ंक्शंस को `React.memo` में लिपटे चाइल्ड कंपोनेंट को प्रॉप्स के रूप में पास करते हैं, तो चाइल्ड री-रेंडर होगा क्योंकि फ़ंक्शन प्रॉप तकनीकी रूप से हर बार एक नया फ़ंक्शन होता है। `useCallback` फ़ंक्शन को ही मेमोइज़ करता है, यह सुनिश्चित करता है कि यह केवल तभी फिर से बनाया जाए जब इसकी निर्भरताएँ बदलें।
• `useMemo()`: `useCallback` के समान, लेकिन मानों के लिए। यह एक महंगी गणना के परिणाम को मेमोइज़ करता है। गणना केवल तभी फिर से चलाई जाती है जब इसकी किसी एक निर्भरता में बदलाव हुआ हो। यह हर रेंडर पर महंगी गणनाओं को रोकने और प्रॉप्स के रूप में पास किए गए स्थिर ऑब्जेक्ट/ऐरे संदर्भों को बनाए रखने के लिए उपयोगी है।

3. स्मार्ट कंपोनेंट कंपोजिशन

आप अपने कंपोनेंट्स को कैसे संरचित करते हैं, इसका प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ सकता है। यदि आपके कंपोनेंट की स्टेट का कोई हिस्सा अक्सर अपडेट होता है, तो उसे उन हिस्सों से अलग करने का प्रयास करें जो नहीं होते हैं।

उदाहरण के लिए, एक बड़े कंपोनेंट के बजाय जहां एक अक्सर बदलने वाला इनपुट फ़ील्ड पूरे कंपोनेंट को री-रेंडर करने का कारण बनता है, उस स्टेट को उसके अपने छोटे कंपोनेंट में उठाएं। इस तरह, जब उपयोगकर्ता टाइप करता है तो केवल छोटा कंपोनेंट री-रेंडर होता है।

4. लंबी सूचियों को वर्चुअलाइज़ करें

यदि आपको सैकड़ों या हजारों आइटम्स वाली सूचियों को रेंडर करने की आवश्यकता है, तो उचित कीज़ के साथ भी, उन सभी को एक साथ रेंडर करना धीमा हो सकता है और बहुत अधिक मेमोरी की खपत कर सकता है। इसका समाधान वर्चुअलाइजेशन या विंडोइंग है। इस तकनीक में केवल उन आइटम्स के छोटे सबसेट को रेंडर करना शामिल है जो वर्तमान में व्यूपोर्ट में दिखाई दे रहे हैं। जैसे ही उपयोगकर्ता स्क्रॉल करता है, पुराने आइटम्स अनमाउंट हो जाते हैं, और नए आइटम्स माउंट हो जाते हैं। `react-window` और `react-virtualized` जैसी लाइब्रेरीज़ इस पैटर्न को लागू करने के लिए शक्तिशाली और उपयोग में आसान कंपोनेंट प्रदान करती हैं।

निष्कर्ष

रिएक्ट का प्रदर्शन कोई दुर्घटना नहीं है; यह वर्चुअल DOM और एक कुशल रिकंसिलिएशन एल्गोरिथम पर केंद्रित एक जानबूझकर और परिष्कृत आर्किटेक्चर का परिणाम है। सीधे DOM मैनिपुलेशन को एब्स्ट्रैक्ट करके, रिएक्ट अपडेट को इस तरह से बैच और ऑप्टिमाइज़ कर सकता है जिसे मैन्युअल रूप से प्रबंधित करना अविश्वसनीय रूप से जटिल होगा।

डेवलपर्स के रूप में, हम इस प्रक्रिया का एक महत्वपूर्ण हिस्सा हैं। डिफिंग एल्गोरिथम के अनुमानी नियमों को समझकर—कीज़ का सही उपयोग करके, कंपोनेंट्स और मानों को मेमोइज़ करके, और हमारे अनुप्रयोगों को विचारपूर्वक संरचित करके—हम रिएक्ट के रिकंसाइलर के साथ काम कर सकते हैं, उसके खिलाफ नहीं। फाइबर आर्किटेक्चर के विकास ने जो संभव है उसकी सीमाओं को और आगे बढ़ाया है, जिससे तरल और उत्तरदायी यूआई की एक नई पीढ़ी को सक्षम किया गया है।

अगली बार जब आप स्टेट परिवर्तन के बाद अपने यूआई को तुरंत अपडेट होते देखें, तो वर्चुअल DOM, डिफिंग एल्गोरिथम, और पर्दे के पीछे होने वाले कमिट चरण के सुंदर नृत्य की सराहना करने के लिए एक क्षण लें। यह समझ वैश्विक दर्शकों के लिए तेज़, अधिक कुशल और अधिक मजबूत रिएक्ट एप्लिकेशन बनाने की आपकी कुंजी है।